Organizational Model in R12
Oracle Financials can be implemented in multiple ways to reflect your real-world organization. Groups generally reflect a tension between their legal organization, management organization, and business divisions.
Standard Business Organization
The following diagram shows an archetypical group of companies operating various business and a standard functional organization.
- A separate card represents each of a series of registered companies, that is, legalentities. The list of cards is the "Legal Axis".
- Each company hosts parts or all of various subdivisions that management has made within its businesses. These are shown as vertical columns on each card. For example, a Group might have a separate company for each business in the United Kingdom, but have their Ireland company host all businesses in that country.
The subdivisions are linked across the cards so that a business can appear on some or all of the cards. For example, the chemical business might be operated by the Ireland, United Kingdom, and France companies. The list of business subdivisions is the "Business Axis". - Each company's card is also horizontally striped by functional groups, such as the sales team and the finance team. The functional list is the "Functional Axis". The overall image suggests that information might, at a minimum, be tracked by company, business subdivision, and function in a group environment.
The Legal Organization
Our ability to buy and sell, own, and employ comes from our charter in the legal system. Commercial groups exist through corporate law. Units in the legal structure of a group are individual companies that share common ownership and control. In a public group, a company is owned by the public through shares sold on a stock market. In a private group, they are held by a privately held holding company. In other organizations, the legal entities are partnerships, funds, or government agencies.
A legally recognized entity can own and trade assets and employ people; while an entity without legal recognition cannot. When granted these privileges, legal entities are also assigned responsibilities to account for themselves to the public (statutory reporting and external reporting), comply with legislation and regulations, and pay income or profit and transaction taxes.
Most groups have many legal entities. They are created to facilitate legal compliance, segregate operations, optimize taxes, and for many other reasons. Legal entities establish your identity under the laws of each nation in which you operate, and provide vehicles for contractual relationships, compliance, and taxation.
Business Divisions
Successfully managing multiple businesses requires that you segregate them by the rewards and risks involved in making them profitable. You divide your organization accordingly and assign management personnel to each division.
Although related to your legal structure, the business organizational hierarchies do not need to be reflected directly in the legal structure of the firm. The management entities and structure include divisions and subdivisions, lines of business, and other strategic business units, and include their own revenue and cost centers.
Functional Organizations
Straddling the legal and business organizations is an organization structured around people and their competencies: sales force, operations, plants, researchers, finance people, human resource management, information technologists, and management. The income statement often reflects their efforts and expenses directly. Organizations must manage and report revenues, cost of sales, and functional expenses such as Research and Development (R&D) and Selling, General, and Administrative Expense (SG&A).
The Legal Entiry in Oracle
- "Legal entity" in the Oracle system corresponds closely to "legal entity" or "company" in the legal world. You can store information about a registered company or other real world legal entity in the "legal entity". For example, you can store the registered address and director or officer names.
- All legal entities exist in particular legal jurisdictions, both national and regulatory, and must comply with the regulations of those jurisdictions. Legal entities have multiple compliance requirements placed on them, many of which define the form of the transactions into which that legal entity enters.
- Individual legal entities own the assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses, and make other transactions.
- Legal entities are formally the entities that actually enter into transactions. Assigning Legal Entity to all transactions enables tax calculation, supporting the centralized tax solution
- The Trading Community Architecture (TCA) model supports four types of parties: organization, person, group, and party relationship. Legal Entities will be stored in TCA as Parties of party type ‘ORGANIZATION’.
- The subsidiaries of the Legal Entities are defined as Establishments. The Establishments are also defined as parties with legal information stored in the Legal Entity Data Model.
You will find that a legal entity has more attributes in Release 12 and that a Legal Entity Configurator is provided. Tax calculation, intercompany processing, and bank ownership exploit legal entity attributes more assiduously than previously.
The system legal entity is the first party on business transactions and is the transaction tax filer and payer. We recognize that for many groups, particularly in environments where the authorities allow you to treat many legal entities as one, you don't need or want to segment data or account separately for each entity that you have incorporated. Therefore, the system legal entity does not automatically account for itself.
Most groups have many legal entities. They are created to facilitate legal compliance, segregate operations, optimize taxes, and for many other reasons. Legal entities establish your identity under the laws of each nation in which you operate, and provide vehicles for contractual relationships, compliance, and taxation.
A given legal entity may or may not represent all or part of a management framework in its domain. For example, in a large country such as the United Kingdom or Germany, you might deploy individual companies to represent each business division, and you might control many companies in that country. In a smaller country, for example Austria, you might use a single legal entity to host all of your business divisions. Legal entities have very specific relationships with shared service centers and with the ownership of the goods and transactions managed by such centers.
Basic difference between 11i and R12
Inventory is used to represent the physical location, production center, distribution area etc. The concept is same both in 11i and R12.
OU is used for operation purpose. We combined few Inv org to represent an OU for the simplicity of business and it helps in operation. All these inv orgs are clubbed together to simplify the procurement, sales and other similar activities. In oracle suppliers, customers are mainlined at this level both in 11i and R12.
The most prominent difference between in 11i and R12 is LE. In 11i GRE/LE is merely used for reporting purpose for tax authorities. In R12 it does more than that. In R12 the LE represents the legal entity which is a registered company and is accountable to everyone including the government, NGOs, etc.
The SOB in 11i has 3Cs. The new addition in R12 is Accounting Convention or Accounting Convention. Like US GAAP, Indian Tax Method, etc
In 11i, Each Inventory is attached with an OU, a LE and a SOB. When we do an inventory level transaction (in BOM, WIP, MRP, Costing) we know to which inv org, OU, LE and BG the account is affecting. The same is true in R12 but instead of SOB it’s PL. In R12, Each Inventory is attached with an OU, a LE and a PL. When we do an inventory level transaction we know exactly which inv org, OU, LE and PL the transaction is affecting.
In 11i, Each OU is attached with a LE and a SOB. When we do an OU level transaction (in AP, AR, OM, PO, iStore, Projects) we know to which OU, LE and BG the account is affecting. But in R12 the concept is different. In R12, we don’t attach any LE to OU. A single OU can do transactions for different LEs. We do provide a default LE context to each OU which is one of the many LEs for which the OU can do a transaction. When we do an OU level transaction we know exactly which PL the transaction is affecting and depending upon the transaction we have to manually select the LE (as in receivable transaction form)or the system ‘ll figure it out for us.
In 11i, Each LE is attached with a SOB. So logically when we do an LE level transaction we know to which SOB the account is affecting. But technically no such transactions are done in 11i. The same is true in R12 but instead of SOB it’s PL. In R12, Each LE is attached with a PL. When we do an inventory level transaction we know exactly which PL the transaction is affecting.